… user-bins 404 (#397)

* fix(bitflow-hodlmm-deposit): allow first-time deposit by handling BFF user-bins 404

`getUserBins` calls `fetchJson` with no error handling. BFF returns HTTP 404
with detail "Pool {pool} not found or user {addr} has no pool bins" when a
wallet has zero existing LP positions in the pool. That is the normal
first-time deposit case (explicitly supported per SKILL.md), not an error,
but the throw bubbles up and crashes `doctor`, `status`, and `run` before
any deposit logic executes.

Wrap the fetch in try/catch. Catch ONLY the specific
`HTTP 404 from ... has no pool bins` response shape and return an empty
bins array. Let any other 404 or API failure propagate unchanged. Downstream
code at line 498+ already handles an empty `bins` array correctly via
`.filter(b => b.userLiquidity > 0n)` — empty array is the right shape for
postcondition-plan adjustment to treat the wallet as a new LP.

Companion fix to staging PR BitflowFinance/bff-skills#583
which patches the same bug in the staging copy of this skill.

Verified end-to-end on Stacks mainnet against three wallet shapes:

- Fresh wallet `SP3YWTZQQ7ZYHG1ECEG6AJAT4KX36W2NA7Q6TCKBG` (was failing):
  doctor and status both now succeed; status preview generates full deposit
  plan (activeBin 648, 3-bin equal-split, slippage-protected minDlp,
  bounded postcondition).
- Wallet with existing positions `SP2G6TM8JCRNK6WSPQE8S86FP2W3A4FEVGZCCCQT8`:
  doctor still works (no regression).
- Wallet with positions in OTHER pools but not this one
  (`SP2G6TM8...` + `--pool-id dlmm_9`): correctly handled as first-time.

Verified across dlmm_1, dlmm_3, dlmm_7 pools. `bun run typecheck` passes.

* docs(bitflow-hodlmm-deposit): note fetchJson error-format coupling in 404 catch

Add a comment flagging that the empty-state catch is coupled to fetchJson's
internal error message format ("HTTP 404 from ..."). If fetchJson's format
ever changes, the catch silently fails — the 404 propagates instead of
returning [], which is safe (no data loss) but the fix stops working with no
diagnostic signal. The note tells a future fetchJson refactor where to look.

Comment-only change; behavior identical to the previous commit.

* fix(bitflow-hodlmm-deposit): clarify active-bin coordinate systems in status preview

The status preview printed `observedActiveBinId` (BFF absolute, e.g. 646)
next to `routerExpectedBinId` (on-chain relative, e.g. 146) with no labels,
making the 500-bin center offset read as router-vs-BFF drift that would
revert at maxDeviation 0.

Verified against the live router (dlmm-liquidity-router-v-1-1
add-relative-liquidity-same-multi) and pool (dlmm-pool-sbtc-usdcx-v-1-bps-10):
the contract's ERR_ACTIVE_BIN_TOLERANCE assert compares its own on-chain
get-active-bin-id (returned 146) against the passed expected-bin-id (646-500=146),
so a synced pool yields delta 0 and passes even at maxDeviation 0. The offset is
by design (MIN_BIN_ID -500 / MAX_BIN_ID 500), not drift.

Rename fields to bffActiveBinId / onChainExpectedBinId and document the
coordinate systems so the broadcast path is not misdiagnosed as blocked.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: macbotmini-eng <macbotmini-eng@users.noreply.github.com>
Co-authored-by: biwasbhandari <biwas2059@gmail.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>